Plansza do analizy bezbłędnej post mortem
Szablon "blameless" post-mortem pomaga zebrać informacje o incydentach, które miały miejsce w produkcji.
Ten „bezwinny” szablon Post-Mortem pomaga zebrać informacje o incydentach, które miały miejsce w produkcji. Przestrzeganie tego procesu oznacza, że inżynierowie, których działania przyczyniły się do wypadku, mogą dostarczyć szczegółowy opis:
jakie działania podjęli i o której godzinie,
jakie skutki zaobserwowali,
oczekiwania, które mieli,
założenia, które przyjęli,
ich zrozumienie osi czasu wydarzeń w miarę ich występowania.
i że mogą podać taki szczegółowy opis bez obawy przed karą lub represjami.
Blameless postmortem obejmuje następujące sekcje
Krok 1. Podsumowanie (wypełnij przed spotkaniem)
Ogólny zarys zgłoszenia, koncentrujący się na tym, co jest obecnie znane i jaki wpływ miało to na klienta. Pozostań przy jednym lub dwóch zdaniach.
Krok 2. Wstępna oś czasu (przed wypełnieniem przed spotkaniem)
Orientacyjna oś czasu zgłoszenia. W zależności od tego, jak szybko rozwijało się zgłoszenie, oś czasu może obejmować od kilku minut do kilku godzin do kilku dni. Jeśli Twoim głównym celem jest poprawa czasu reakcji zespołu w sytuacjach awaryjnych, powinieneś zadbać o to, aby było to mierzone do sekundy.
Podczas rejestrowania osi czasu, upewnij się, aby uwzględnić:
Kiedy zgłoszenie zostało zarejestrowane i przez kogo/jakiego procesu
Jakie działania zostały podjęte
Kiedy komunikacja była realizowana do i z zespołu
Pomysły na usunięcie skutków
Kiedy spotykasz się, aby omówić zgłoszenie, zaproś wszystkich, którzy pracowali nad zgłoszeniem. Obejmuje to zespół pomocy technicznej oraz członków zespołu obsługi klienta, którzy mogli być zaangażowani.
Przejrzyj podsumowanie, przeanalizuj harmonogram i dodaj brakujące części, a następnie przejdź do pomysłów na remediację.
Te pytania są sformułowane, aby pomóc zespołowi wziąć odpowiedzialność za problem. Istnieją pewne problemy, które wydają się być poza kontrolą zespołu (centrum danych traci zasilanie, itp.). Ale nawet w takich wydarzeniach zespół może wciąż poprawić swoją reakcję na katastrofę.
Krok 3. Wykrywanie – Jak możemy wykryć ten problem lub podobny szybciej?
Przyjmij, że ten problem lub bardzo podobny wystąpi ponownie. Jak zespół pomocy może szybciej wykryć ten problem i znaleźć go zanim zrobi to klient?
Krok 4. React – Jak możemy poprawić naszą reakcję na takie zgłoszenia?
Przyjmijmy, że zgłoszenie zostało zgłoszone. Jak szybka była reakcja? Czy stracono minuty, gdy ludzie wysyłali e-maile, próbując nakłonić kogoś do zajęcia się problemem?
Kiedy następnym razem pojawi się ten problem, jak zespół może zareagować szybciej lub w bardziej zorganizowany sposób?
Krok 5. Szybkie rozwiązanie – Jak szybciej zatamować krwawienie?
Czy gdy to się powtórzy, mamy gotowe rozwiązanie dla klienta, które pozwoli zmniejszyć wpływ problemu?
Jeśli to coś, co pogarsza się z czasem (jak atak DDOS), czy mamy szybki sposób na zamknięcie dopływu danych, podczas gdy ustalamy przyczynę źródłową?
Krok 6. Zapobieganie – Jak możemy zapobiec lub zmniejszyć wpływ problemów w przyszłości?
To często jedyne pytanie, które zespoły zadają na spotkaniach postmortem. To ważne pytanie i powinieneś spędzić tutaj dużo czasu. Jednak jeśli ograniczasz się do pytania tylko o to, jak zapobiec zgłoszeniu, unikasz wzięcia odpowiedzialności za rzeczy, które są pod twoją kontrolą (jak sposób, w jaki wykrywasz, reagujesz czy szybko naprawiasz zgłoszenie).
Podczas przeprowadzania burzy mózgów nie ograniczaj się do rozwiązań technicznych. Lepsze monitorowanie, lepsze ścieżki komunikacji, lepsze szkolenia, upewnianie się, że osoby w dziale obsługi klienta znają osoby w dziale pomocy produkcyjnej po imieniu itp.
Krok 7. Inne obszary ryzyka – Jakie inne obszary mają tę samą podatność?
Każde zgłoszenie jest wskazówką, gdzie system jest słaby. Prawdopodobnie na każde zgłoszenie, które znajdziesz, przypadają dziesiątki ukrytych w cieniu, czekających na odkrycie.
Tak jak, gdybyś zobaczył mysz w swojej kuchni. Nie masz problemu z „myszą”, tylko z „myszami”.
Istnieją prawdopodobnie inne części systemu, które dzielą te same założenia projektowe lub w niektórych przypadkach ten sam kod (nie żeby ktoś kiedykolwiek kopiował/wklejał kod).
Poświęć kilka minut na przeprowadzenie burzy mózgów nad innymi miejscami, które są podatne w podobny sposób.
Kiedy zespoły są zestresowane i przemęczone, pomijają ten krok. Uważam, że jest to najważniejsze pytanie, które należy zadać, aby wprowadzić zespół w proaktywny sposób myślenia i zmniejszyć występowanie problemów w przyszłości.
Krok 8. Kolejne Kroki (Działania)
Po zidentyfikowaniu wszystkich możliwych działań, które możesz podjąć, aby poprawić wykrywanie, reakcję, szybkie naprawy i zapobieganie zgłoszeniom… oraz po znalezieniu innych obszarów aplikacji wymagających uwagi… przejdź do podejmowania decyzji, jakie działania wybrać.
To, jak ustalisz priorytety, zależy od Ciebie. Mam jednak kilka rad.
Uzyskaj nazwę i datę dla każdego działania, które planujesz podjąć przed opuszczeniem spotkania.
Jeśli ktoś na spotkaniu jest chętny do podjęcia się jednego z działań, zachęć go do tego, nawet jeśli uważasz, że może to nie być najważniejsza kwestia do rozwiązania.
Nazwy i daty
Ogólnie stwierdziłem, że zespoły cieszą się z tego ćwiczenia (pod warunkiem, że możesz stworzyć środowisko bez obwiniania dla spotkania). Lubią analizować problem i przeprowadzać burzę mózgów nad rozwiązaniami. Jednak wszyscy czują się zajęci i przepracowani. Jeśli to spotkanie nie zakończy się przypisaniem właścicieli i terminów do rzeczy, które trzeba wykonać, istnieje duże prawdopodobieństwo, że żadne z usprawnień się nie wydarzy.
Co się stanie, to że za 3 tygodnie, kiedy ten sam problem pojawi się na produkcji (ale tym razem na większą skalę), ktoś powie: „O tak, rozmawialiśmy o naprawieniu tego.” Nie najlepsze miejsce do przebywania.
Aby temu przeciwdziałać, po prostu upewnij się, że przy każdej akcji, którą grupa chce podjąć, znajduje się imię i data.
Gra Kanban Pizza
Zastosowania:
Agile, Kanban
Kanban Pizza Game to interaktywny sposób dla zespołów na naukę i stosowanie zasad kanban. Symulując proces dostawy pizzy, zespoły doświadczają, jak wizualizować pracę, ograniczać pracę w toku i optymalizować przepływ. Dzięki iteracyjnym rundom i refleksji uczestnicy zyskują wgląd w ciągłe doskonalenie i myślenie lean, co sprzyja współpracy i zwiększa wydajność. Przygotuj się na eliminację nieefektywności i szybsze dostarczanie wartości dzięki grze Kanban Pizza!
Retrospektywa piłkarska
Zastosowania:
Metodyka Agile, Retrospektywy, Spotkania
Szablon Soccer Retrospective oferuje podejście do retrospektyw o tematyce sportowej, używając gry w piłkę nożną jako metafory pracy zespołowej i strategii. Zapewnia elementy do refleksji nad osiągnięciami z przeszłości, analizy mocnych i słabych stron oraz wyznaczania celów na poprawę. Ten szablon sprzyja zarówno konkurencyjności, jak i współpracy, zachęcając członków zespołu do wspólnej pracy na rzecz osiągnięcia wspólnych celów. Wykorzystując metaforę piłki nożnej, Retrospektywa Piłkarska umożliwia zespołom udoskonalanie swoich taktyk, poprawę komunikacji i skuteczne osiąganie celów.
Szablon retrospektywy 4 L
Zastosowania:
Retrospectives, Decision Making
Właśnie ukończyliście sprint. Zespoły dały czadu, a emocje sięgały zenitu. Teraz spójrz trzeźwo w przeszłość i uczciwie oceń sprint – co zadziałało, co nie, a co można poprawić. Ta metoda (4L to skrót od <i>liked</i> – podobało mi się, <i>learned – </i>nauczyłem się, <i>lacked</i> – brakowało mi i <i>longed for</i> – tęskniłem za) to nieoceniony sposób na pozbycie się emocji i krytyczne spojrzenie na proces. W ten sposób można budować zaufanie, poprawiać morale i zwiększać zaangażowanie, a także wprowadzać zmiany, aby być bardziej produktywnym i skutecznym w przyszłości.
Szablon analizy DMAIC
Zastosowania:
Agile Methodology, Design Thinking, Operations
Procesy mogą nie wydawać się najprzyjemniejszą rzeczą do analizowania, mogą się jednak opłacić - bardziej wydajny proces pozwala przyczynić się do sporych oszczędności kosztów i uzyskania lepszego produktu. Tym właśnie zajmuje się analiza DMAIC. Opracowany w ramach inicjatywy Six Sigma, DMAIC jest opartą na danych strategią jakości służącą usprawnianiu procesów i rozwiązywaniu zgłoszeń. Technika ta jest podzielona na pięć podstawowych kroków, które są wykonywane w następującej kolejności: definiuj, mierz, analizuj, ulepszaj i kontroluj.
Szablon planowania funkcji
Zastosowania:
Desk Research, Agile Methodology, Product Management
Funkcje są tym, co sprawia, że produkt lub usługa są zabawne, ale dodawanie nowych to nie prosta sprawa. Wymaga to wielu kroków - ideacji, projektowania, udoskonalania, budowania, testowania, uruchamiania i promowania - i równie wielu stakeholderów. Planowanie funkcji pozwala wdrożyć płynny, solidny proces, dzięki czemu możesz pomyślnie dodać funkcję, poświęcając na to mniej czasu i zasobów. To sprawia, że nasz szablon planowania funkcji jest dobrym punktem wyjścia dla każdego, kto chce dodać nowe funkcje produktu, zwłaszcza dla członków zespołów ds. produktu, inżynierii, marketingu i sprzedaży.
Szablon mapy historii użytkownika
Zastosowania:
Marketing, Desk Research, Mapping
Spopularyzowana przez Jeffa Pattona w 2005 roku technika mapowania historii użytkowników to sprawny sposób zarządzania rejestrami produktu. Niezależnie od tego, czy pracujesz sam, czy z zespołem produktowym, możesz wykorzystać mapowanie historii użytkowników do planowania kolejnych wersji produktu. Mapy historii użytkowników pomagają zespołom skupić się na wartości biznesowej i wydawać te funkcje, na których zależy klientom. Struktura pomaga uzyskać wspólne zrozumienie w wielofunkcyjnym zespole tego, co należy zrobić, aby zaspokoić potrzeby klientów.